Subject: Scope of work

From: Robin Layland <[email-masked]>
Date: Tue, 10 Aug 93 21:00 GMT

>Personally I'd like to get a better  idea of whether this group's goal is
>to complete some extensions to RFC  1434 that everybody can implement and
>ship in  the very  near future,  and claim  interoperability with,  or to
>reinvent an architecture  with the sophistication and  scope of something
>like APPN.  My impression from most of  you was that it's the former.  Is
>that the general sense of the group?
Robin Layland......  
 
Yes it seems that DLSw is reinventing thing APPN has done. It is true that the
road DLSw is taking with talk about scalability issues is inlarging DLSw beyond
what it was original planned for. I am all for DLSw taking this road.
 
The reason is simple. SNA and Netbios are too important to have something that
doesn't address the issues fully. DLSw will compete agains APPN/DLUR. APPN/DLUR
is solving one of the problem DLSw is also solving, how to handle PU 2 traffic
in an Internetwork. Which is best? Who knows? 
 
I agree with Wayne Clark that the market will decide. If more vendors and users
get behind DLSw, then it will win. The group working on DLSw has to continue to
improve it as the group see best. If that means redo what APPN has done, so be
it. Remember APPN is an IBM architecture. The goal of the DLSw is to make DLSw
an open standard. 
>The differences  between what  each contributor  prioritizes high  or low
>seems to  depend on your view  of the market and  market requirements for
>your product(s).  For  an interoperability standard, shouldn't  we try to
>determine what areas  of market requirements the router  community has in
>common,  and  let  the  less-popular  items  be  "towers"  indicated  via
>capabilities exchange?
 
Robin Layland
 
This would be a good issue to bring up to the entire DLSw group. Do you have a
list (or anybody) or what should not be include?
I have seen comments about Netbios not be in the base. I feel strongly that
Netbios should be include. UI frames is another issues that may be less-popular.
Again I feel the UI are two important to drop, they can cause a lot of problems
in a network, especially if they are broadcast messages. DLSw can add a lot of
value handling them.

>Comments/feedback welcome.
 
>      Marcia
_

---

From: [email-masked] (David Matusow)
Date: Wed, 11 Aug 93 12:03:53 -0400

>   Date: Tue, 10 Aug 93 21:00 GMT
>   From: Robin Layland <[email-masked]>
>   To: aiw sig dlsw connect <[email-masked]>
>   Subject: Scope of work
>   
>    
     
This is what I was saying a few weeks ago; for example, the directory 
service that some were speaking of was a reinvention of the APPN DS.  As
this is a MAJOR piece of code, it doesn't seem that we should or could
provide this for DLS.  We need to keep in mind the requirements that
we are trying to fill...and "solving the world's problems" is not
within our scope.

>   in an Internetwork. Which is best? Who knows? 

I don't see DLUr as competing against DLS.  That address different issues.
DLUr is to allow dependent LUs to be transported across an APPN network.
DLS is to allow interoperability of routers in transporting SNA.  I guess
it comes back to the question of whether APPN or TCP or going to be
"the answer".  Of course, the market might say that they both are
desired.  They really address different marketplaces and thus could
easily BOTH survive and flourish.

>   in a network, especially if they are broadcast messages. DLSw can add a lot of

from experience, I'd agree that the broadcast frames are a killer item
that DLS should have an answer for (and we do!).  Other LLC1 frames could
be taken through an internet without having to impose these on DLS.
As they are LLC1, a connectionLESS protocol, what harm would there be in
bridging them across outside the TCP pipe?  It seems to me that this 
is where they belong.

David Matusow
Hypercom